Method and system for object-oriented management of multi-dimensional data

ABSTRACT

Methods and systems for managing and analyzing multi-dimensional data are provided. Example embodiments provide a Meta-Object Data Management System “MODMS,” which enables users to arrange and to rearrange the hierarchical relationships of the data on an ad-hoc basis and allows the data to be analyzed using any set of attributes (dimensions) while the system is running. The MODMS represents heterogeneous data in a normalized (standardized) fashion using an object type management system that allows the arbitrary coercion of one type of object into another different type of object and automatically resolves attribute dependencies. In one embodiment, the MODMS comprises an object type management subsystem; a meta-object instantiation subsystem; one or more data repositories that hold, for example, the data used to populate objects and object type definitions; and an input/output interface. These components cooperate to allow the creation, management, and analysis of relationships between many different types of single and multi-dimensional data. In one embodiment, the MODMS is used to implement an enterprise portfolio management system.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to methods and systems for managingmulti-dimensional data and, in particular, to methods and systems forcreating, maintaining, and analyzing portfolios of multi-dimensionaldata, such as project, asset, and product investments, using anobject-oriented paradigm.

2. Background Information

Today's companies, institutions, and other organizations are plagued bythe vast amount of data which is now stored electronically and oftenneeds to be analyzed by a variety of persons within the organizationrelative to business or organizational goals. The need to determineefficiently what data is available for analysis and how to analyzedisparate data across organizational management boundaries is anever-increasing problem as the data being tracked increases and asorganizations implement more specialized or distributed functions.Managers, executives, employees, and other personnel, each with possiblydiffering needs for particular content and detail, need to analyze howdifferent changes might effect the projects, products, resources,finances, and assets that each are responsible for. Rapid planningcycles, optimizing the use of critical resources, eliminating low value,non-strategic, redundant, and poorly performing assets and projects, andreal time visibility of results are common goals in today'sorganizations.

The idea of “portfolio management” has evolved within such organizationsas a way to emphasize that all assets of an organization, be theyfinancial, human, equipment resources, human resources or other assets,require management and oversight in the same manner as traditionalinvestments such as real property, commercial paper, and equityinvestments. Managing a group of assets as a portfolio encouragesdecision makers to view the member investments as a whole but also beable to analyze and scrutinize each discrete investment. Portfolio-basedmanagement of IT assets, such as technology investments, has become apopular example of applying portfolio management in a modern dayorganization. With portfolio-based management, IT information such asinventory lists, spreadsheets, and project management data are managedas assets that need to be analyzed as to how well they are meeting ITand organizational level objectives.

Traditionally, discrete systems have been developed to handle the datamanagement and analysis needs of various entities within anorganization. This phenomenon has grown out of the situation that thedata for each entity is typically stored in its own subsystem andanalysis tools have been developed that are targeted for the specificneeds of that entity. Thus, to date, portfolio management systems havebeen created to separately manage each type of investment. For example,extensive financial management and analysis systems have been developedand used to analyze the financial assets of an organization such asstocks, bonds, and other commercial paper. Classically, the data forthese systems is stored in a variety of (typically) relational data basemanagement systems (RDBMS) so that queries can be executed to gainhistorical insight into the data. “What-if” scenarios are often handledby separate analysis packages that are specific to the type of databeing analyzed and the type of analysis conducted. On-line analysisprocessing packages (OLAP packages) have been developed to support such“what-if” analysis with data that have a large number of axes/variables(often referred to as multi-dimensioned data). For example, an inventorycontrol system of a geographical distributed company may have resourcedata that can be viewed, analyzed, and sorted by geographic location,region, type of resource, date placed in operation, organization,responsible party, etc. An OLAP package attempts to collect and storesuch data according to how the data is expected be analyzed so as tooptimize analysis efficiency (by reducing search times). In order toanalyze the same data according to different views, the system is takenoff-line and the data structures are recalculated to prepare foradditional analysis. This can be a very time consuming and burdensomeprocess if the data set is very large, as is typical.

Similarly, to handle project management, separate project management andanalysis systems have been developed to aid managers and otherexecutives in the project planning and execution lifecycles of projectswithin an organization. For example, there are systems that offerextensive milestone, critical path, and resource analysis fororganization data that can be defined as a project. There exist toolstoday that allow a group of projects to be viewed as “investments”within a portfolio. These tools provide a way for project managers andother executives within an organization to analyze the costs andbenefits of such projects in a similar manner to how financial analystsanalyze financial investments.

BRIEF SUMMARY OF THE INVENTION

Embodiments of the present invention provide enhanced computer- andnetwork-based methods and systems for managing and analyzingmulti-dimensional data. Multi-dimensional data is data having a largeplurality of attributes, such as data found in enterprise managementsystems. Example embodiments provide a Meta-Object Data ManagementSystem (“MODMS”), which enables users to arrange and to rearrange thehierarchical relationships of the data on an ad-hoc basis so that thedata may be analyzed using any set of attributes (dimensions) while thesystem is running. The MODMS stores heterogeneous data in a normalized(standardized) fashion using an object type management system, whichallows the arbitrary coercion of one type of object into anotherdifferent type of object and automatically resolves attributedependencies. The arbitrary coercion of one type of object into anotherdifferent type of object permits and supports a system whereby any typeof investment can be contained within any other type of investment, soinvestments can be moved within and across portfolios at will.

The Meta-Object Data Management System provides techniques for creating,managing, and analyzing relationships between, typically, heterogeneous,multi-dimensional data. In one example embodiment, the Meta-Object DataManagement System comprises one or more functional components/modulesthat work together to implement an enterprise portfolio managementsystem.

According to one approach, a Meta-Object Data Management Systemcomprises an object type management subsystem, a meta-objectinstantiation subsystem, one or more data repositories that hold thedata used to populate objects and object type definitions (for whateverother data is being managed), and an input/output interface. Forexample, the data repositories may store the financial investment dataand the project management (investment) data of the enterprise. Theobject type management subsystem is used to define objects thatcorrespond to the various data types (e.g., investment types) that willbe created and managed by the MODMS. The meta-object instantiationsubsystem is used to create instances of object types defined by theobject type management system. The input/output interface represents anyinterface to the components of the MODMS and make take the form of auser command interface or a programmatic interface, such as anapplication programming interface definition.

In one aspect, each meta-object comprises an object identifier, anobject type, and an attribute block. In another aspect, each object typeis a collection of attributes defined from a global attributes datastructure. An object type definition can be dynamically andautomatically changed, by modifying one of the global attributesassociated with that object type. When an object type definition ischanged, the MODMS automatically adjusts each instantiated meta-objectthat is associated with that object type without recompiling orrecreating the meta-objects. In yet another aspect, meta-objects do notobey traditional inheritance rules, and thus each meta-object can betype cast into a different object type. In another aspect, an attributeblock stores all of the attribute values for a single meta-object. Eachattribute value is stored between a beginning attribute tag and anending attribute tag that identifies the attribute. The attributetag-value pairs are stored in a serialized single variable within themeta-object. In one of these aspects, the tags are XML tags.

In another aspect, multi-dimensional views of the data can bedynamically created through the use of datasheets. A datasheet attributespecification is defined, and a corresponding datasheet is computedbased upon the object instance associated with the datasheet. Whendatasheets are moved and copied to different locations, their resultantdata and presentation is automatically adjusted for the new location. Inone of these aspects, a datasheet is represented using a virtual objecttree. A virtual object is generated for each grouping of data thatmatches a discrete combination of values of the attributes identified bythe datasheet attribute specification. Then, a virtual object isgenerated for each specified group of groups, until all groupings andsub-groupings have been associated with virtual objects.

In yet another aspect, charts that represent multi-dimensional views ofthe data can also be dynamically created. Each chart is associated witha datasheet and the structure of the chart can automatically reflect thedimensions of the datasheet, or be manually controlled. Once a chartstructure has been created, the presentation displayed by the chartstructure can be automatically modified by selecting a different axis ofthe data to be presented. The resulting chart is then automaticallypopulated using values of the underlying datasheet.

According to another approach, a portfolio management system is createdusing the MODMS. The portfolio management system comprises a portfoliomanager for instantiating meta-objects to correspond to portfolio dataand a portfolio analyzer for displaying instantiated meta-objects whoseattribute values match an attribute specification.

In an example portfolio management system, heterogeneous investmentdata, for example financial investments and project management resourceinvestments are managed and analyzed using a single abstraction, ameta-object. In addition, each investment data item can be converted toa different type of investment data item without reentering the originaldata. Investment data can be dynamically organized within otherinvestment data irrespective of the type of investment data.

All of these approaches and aspects and other approaches and aspects aresupported by the methods and systems of a Meta-Object Data ManagementSystem.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an example block diagram of components of an exampleMeta-Object Data Management System.

FIG. 2 is an example overview flow diagram of typical operations of anexample Meta-Object Data Management System.

FIG. 3 is an example block diagram abstraction of an object typedefinition created and managed by an example object type managementcomponent of a Meta-Object Data Management System.

FIG. 4 is an example block diagram of an example meta-object.

FIG. 5 is an example block diagram of an in-memory data structurerepresentation of time-phased attribute.

FIG. 6 is a block diagram of an example storage representation of ameta-object.

FIG. 7 is a block diagram of an abstraction of an example meta-objectinstance hierarchy created using an example Meta-Object Data ManagementSystem.

FIG. 8 is an example overview flow diagram of a command interpreter foran example Meta-Object Data Management System.

FIG. 9 is an example flow diagram of a Change Object Type Definitionroutine for modifying an object type definition in an exampleMeta-Object Data Management System.

FIG. 10 is an example flow diagram of an Update Meta-Object routine formodifying an instantiated meta-object in an example Meta-Object DataManagement System when its object type definition has changed.

FIG. 11 is an example flow diagram of an Adjust Rollups routine foradjusting rollup attributes.

FIG. 12 is an example flow diagram of steps executed by a typical rollupevent.

FIG. 13 is an example block diagram of a general purpose computer systemfor practicing embodiments of a Meta-Object Data Management System.

FIGS. 14 and 15 are example block diagrams of a client-server,network-based tiered architecture for implementing embodiments of aMeta-Object Data Management System.

FIG. 16 is an example block diagram of components of an example objectservices layer of a Meta-Object Data Management System used to implementan example Enterprise Portfolio Management System.

FIG. 17 is a block diagram of an example Enterprise Portfolio ManagementSystem implemented using an example Meta-Object Data Management System.

FIG. 18 is a block diagram of an example investment instance hierarchyof a hypothetical enterprise portfolio management system created using aMeta-Object Data Management System.

FIG. 19 is an overview flow diagram of example portfolio managementfunctions of a portfolio manager component of an example EnterprisePortfolio Management System.

FIG. 20 is an example flow diagram of an Add New Meta-Object routine foradding a new meta-object (investment).

FIG. 21 is an example flow diagram of a Move/Copy Meta-Object routinefor moving/copying a new meta-object (investment).

FIG. 22 is an example flow diagram of a Delete Meta-Object routine fordeleting a meta-object (investment).

FIG. 23 is an example flow diagram of a Change Meta-Object routine forchanging an existing meta-object (investment).

FIG. 24 is an overview flow diagram of example portfolio analysisfunctions of a portfolio analyzer component of an example EnterprisePortfolio Management System.

FIG. 25 is an example flow diagram of a Create Multi-Dimensional Viewroutine for creating a multi-dimension view (datasheet) of an exampleportfolio.

FIG. 26 is an example flow diagram of a Build Presentation routine forbuilding a presentation for a multi-dimension view.

FIG. 27 is an example flow diagram of a Move/Copy Multi-Dimensional Viewroutine for moving/copying a multi-dimension view.

FIG. 28 is an example flow diagram of a Delete Multi-Dimensional Viewroutine for deleting a multi-dimension view.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the present invention provide enhanced computer- andnetwork-based methods and systems for managing and analyzingmulti-dimensional data. Multi-dimensional data is data having a largeplurality of attributes, such as data found in enterprise managementsystems. Example embodiments provide a Meta-Object Data ManagementSystem (“MODMS”), which enables users to arrange and to rearrange thehierarchical relationships of the data on an ad-hoc basis and allows thedata to be analyzed using any set of attributes (dimensions) while thesystem is running. Thus, analysis of the data can appear to occurconcurrently with transactions on the underlying data. The MODMSrepresents heterogeneous data in a normalized (standardized) fashionusing an object type management system that allows the arbitrarycoercion of one type of object into another different type of object andautomatically resolves attribute dependencies. Attribute dependenciesoccur when the values of attributes of one object are calculated ordependent upon attribute values of another object. Such dependencies areuseful in portfolio management applications where, for example, valuesthat correspond to a cost attribute of multiple investment line itemsare aggregated (rolled-up) into a summary line item that represents thecost attribute of the portfolio as a whole. The arbitrary coercion ofone type of object into another different type of object permits andsupports a system whereby any type of object can be contained within anyother type of object, so, for example, investments in a portfoliomanagement system can be moved within and across portfolios at will.

The Meta-Object Data Management System provides techniques for creating,managing, and analyzing relationships between, typically heterogeneous,multi-dimensional data. In one example embodiment, the Meta-Object DataManagement System comprises one or more functional components/modulesthat work together to implement an enterprise portfolio managementsystem. One skilled in the art will recognize, however, that thetechniques of a MODMS may be used for the creation, management, andanalysis of relationships between many different types of single andmulti-dimensional data, and is not limited to use with portfoliomanagement.

FIG. 1 is an example block diagram of components of an exampleMeta-Object Data Management System. One skilled in the art willrecognize that these components may be implemented in software orhardware or a combination of both. As shown, a Meta-Object DataManagement System may comprise an object type management subsystem 101;a meta-object instantiation subsystem 102; one or more data repositories103-104 that hold, for example, the data used to populate objects andobject type definitions (for whatever data is being managed); and aninput/output interface 105. For example, the data repository 103 maystore the financial investment data of an enterprise and the datarepository 104 may store the project management (investment) data of theenterprise. The object type management subsystem 101 is used to defineobject types that correspond to the various data types (e.g., investmenttypes) that will be created and managed by the MODMS. The meta-objectinstantiation subsystem 102 is used to create instances of the objecttypes defined by the object type management system 101. The input/outputinterface 105 represents any interface to the components of the MODMSand make take the form of a user command interface or a programmaticinterface, such as an application programming interface definition.

More specifically, the object type management subsystem 101 defines andmanages global attributes and creates and manage object typedefinitions, which are each a collection of one or more globalattributes. An excerpt from an example set of global attributedefinitions for an example enterprise portfolio management system isattached as Appendix B, which is herein incorporated by reference in itsentirety. Example global attributes may include characteristics of thedata to be stored and analyzed such as a description, cost to date,tangible benefits, intangible benefits, etc., or any other definablecharacteristic whose value can be specified. Global attributes can beadded, deleted, and modified while the MODMS is running. Once an objecttype definition is created, its collection of attributes can beadjusted. For example, attributes can be added to or deleted from anobject type definition. Further, when an attribute definition isadjusted, any changes are percolated throughout the object typedefinitions that include that attribute.

The meta-object instantiation subsystem 102 supports the creation ofinstances of objects that are defined by the object type managementsystem 101. The meta-object instantiation subsystem 102 implements anabstraction of a “higher level” object, known as a meta-object, that isnot tied to a particular object type, but rather implements a broaderobject concept that is used to unify the creation and management of allobject types that correspond to user data. For example, within aportfolio management system, a meta-object is instantiated (created) tocorrespond to each “investment” type in the system, including, forexample, portfolios, projects, products, financial assets, equipment,initiatives, operations, applications, processes, activities, humanresources, other resources, other assets, etc. A representation of ahierarchy of investments is created based upon the relationships desiredbetween investments by instantiating a meta-object that corresponds toone investment as a child of another meta-object that corresponds toanother investment. The object type definitions themselves do not definethe containment or inheritance relationships as common in otherobject-oriented systems. Rather, the containment hierarchy ofinstantiated meta-objects defines the relationships between theinvestments. Once meta-objects are instantiated, they can be moved,copied, deleted, and their attributes changed. When a meta-object ismoved or copied, the attribute values of the original parent meta-objectinstance and the new parent meta-object instance that are dependent uponchildren meta-object instances are automatically adjusted (rolled up) toreflect the new containment structure. Thus, for example, when aninstantiated investment object is moved to a new portfolio, theattributes of the original parent portfolio and the new parent portfolioare automatically recomputed. Similarly, when an object type definitionis changed, instantiated meta-objects of the modified object type areautomatically adjusted to reflect changes to the object type definition.Thus, for example, if the definition of a human resource object type ischanged to add an “age” characteristic, then instances of human resourceobjects already created by the meta-object instantiation system 102 areautomatically updated to include an “age” attribute with a defaultvalue.

In addition to defining representations for types of objects and formanaging the data associated with them, the MODMS supports theconcurrent analysis of data (e.g., investment data) through the use ofdatasheets. A datasheet is a multi-dimensional view of the underlyinginstance hierarchy based upon a datasheet attribute specification (e.g.,a property sheet). For example, a new multi-dimensional view of theportfolio investment hierarchy can be formed dynamically byinstantiating a new datasheet based upon specified properties. In oneembodiment, the datasheet properties (the attribute specification)specify axes (data columns of interest), grouping, sorting, andfiltering. A corresponding datasheet is then determined (calculated) bythe system and displayed. Once a datasheet is generated, its propertiescan be adjusted, thereby causing an automatic adjustment andrecalculation of the resultant datasheet. In one example embodiment, adatasheet is associated with a particular meta-object in the instancehierarchy and relates to the objects within that sub-tree of thecontainment hierarchy. A datasheet (or more precisely, its attributespecification) can be deleted, moved, or copied, thereby automaticallycausing adjustments to be made to the resultant datasheet dependant uponrevised location and adjustments to be made to the associatedmeta-object if applicable.

Although the techniques of a Meta-Object Data Management System aregenerally applicable to any type of investment, the terms “investment”and “asset” are used generally to imply any type of data having one ormore attributes whose cost or benefit can be assessed. One skilled inthe art will recognize that an investment is not limited to traditionalinvestment types such as real property, commercial paper, and equityinvestments. Rather, a MODMS can be used to support the creation,management, and analysis of any type of data object, whether commonlyconsidered an “investment” or not.

Also, although the examples described herein often refer to portfoliomanagement and enterprise portfolio management, one skilled in the artwill recognize that the subsystems (components) of a MODMS are definedgenerically and that the techniques of the present invention can also beused in any system that desires to create and manage different types ofdata objects whose relationships to each other may change over time. Inaddition, the concepts and techniques described are applicable to otherdata management systems, including other types of applications that usedata repositories to store related information, for example, inventorycontrol systems, product databases, manufacturing systems, corporatefinances, etc. Essentially, the concepts and techniques described areapplicable to any data management environment. In the followingdescription, numerous specific details are set forth, such as dataformats and code sequences, etc., in order to provide a thoroughunderstanding of the techniques of the methods and systems of thepresent invention. One skilled in the art will recognize, however, thatthe present invention also can be practiced without some of the specificdetails described herein, or with other specific details, such aschanges with respect to the ordering of the code flow.

In addition, although certain terms are used primarily herein, oneskilled in the art will recognize that other terms could be usedinterchangeably to yield equivalent embodiments and examples. Forexample, it is well known that equivalent terms could be substituted forsuch terms as “object,” “attribute,” “dimension,” etc. In addition,terms may have alternate spellings which may or may not be explicitlymentioned, and one skilled in the art will recognize that all suchvariations of terms are intended to be included.

FIG. 2 is an example overview flow diagram of typical operations of anexample Meta-Object Data Management System. In step 201, the MODMSsupports the setup (creation) or management of a global attributetables. The global attribute tables are used in step 202 to define(create) object types. One skilled in the art will recognize that anywell-known technique can be used to implement a global attributes table,and that any data structure equivalent of a “table” may be employed.Each object type definition is based upon a collection of globalattribute definitions and a set of methods (functions) shared by allmeta-objects. Typically, as shown in the example global attributes tableexcerpt of Appendix B, each global attribute is associated with one ormore attribute values and the table contains one or more “attributevalue definitions” (fields) that describe how each attribute value to beused or interpreted. Each attribute may define more than one set ofvalues. For example, an attribute may define one set of values thatcorrespond to target values and define a different set of values (andpotentially calculations) that correspond to actual values. An attributethat defines multiple sets of values is referred to as a “dimensioned”attribute. One skilled in the art will recognize that a dimensionedattribute is an attribute that defines multiple value sets and that eachdimension instead could be represented as its own attribute. In theexample global attribute table excerpted in Appendix B, each attributedefinition contains a tag name for identification, a descriptive name,an indication of whether multiple attribute values (dimensions) areassociated with the attribute and, for each dimension of the attributeor for a single valued attribute, an attribute value definition, whichis a set of fields as that further define that value. For example, eachattribute value definition typically defines:

-   -   if dimensioned, a type of dimension (e.g., target, plan,        baseline, scenario, actual);    -   an indication of whether the attribute value can be rolled up to        a corresponding parent attribute value and, if so, the type of        roll-up function associated with that value;    -   an indication of whether the attribute value is calculated, and,        if so, the calculation function for that attribute value;    -   an indication of whether the attribute value is a time-phased        attribute and, if so, then the type of time-phased attribute is        indicated.        Generally, time-phased attributes are attributes that have        discrete values or ranges of values over periods of time, and        described in more detail with reference to FIG. 5. Other fields        and types of values (not shown) may also be defined in an        attribute value definition and in an attribute definition. In        step 203, meta-objects are instantiated using the created object        types to correspond to the data that is to be managed and        analyzed. In step 204, these meta-objects are persisted into        storage. Then in step 205, a command interpreter is invoked to        handle requests to manipulate the instantiated meta-objects and        to manage the object type management subsystem.

An administrator of an application that incorporates the MODMS typicallyuses an interface to the object type management system to define objecttypes for the data to be manipulated by the application. Theadministrator creates a new object type (using well-known types ofinterfaces such as dialog boxes, tables, forms, Q&A etc.) by determiningwhich of the global attributes are grouped together to form the newobject type. FIG. 3 is an example block diagram abstraction of an objecttype definition created and managed by an example object type managementcomponent of a Meta-Object Data Management System. Each object typedefinition 301 created by the object type management component of aMODMS comprises at least an object type identifier 302 and a collectionof one or more attributes 303. Each attribute of the collection 303 isan indicator to an attribute definition 310 stored in the MODMS, forexample as one or more rows of a table similar to the table described inAppendix B. The data structures shown in FIG. 3 are abstractrepresentations of the data, and one skilled in the art will recognizethat any well-known method for storing tabular or linked information maybe used. An attribute definition 310 defines all of the fields thatcomprise the attribute. As described with reference to FIG. 2, eachattribute definition 310 typically comprises a descriptive name field311, an identification tag name field 312, and an indicator to one ormore attribute value definitions, for example, attribute valuedefinition 314. When the attribute definition 310 defines a dimensionedattribute, then an indicator 313 is present that refers to multipleattribute value definitions 330 through a dimensioned attribute table320. Specifically, for each value set that comprises a dimension of theattribute, there is an indicator, such as indicators 321-325 in thedimensioned attribute table 320 that refers to an attribute valuedefinition 330. The different value sets for a dimensioned attribute maycorrespond, for example, to target values 321, plan values 322, baselinevalues 323, actual values 325, and other such value sets 324. Thesedifferent dimensions of an attribute are present to convey the conceptthat a single attribute may have different values depending upon itspurpose, lifecycle state, or for other reasons. Each attribute valuedefinition 314 or 330 comprises, for example, a type of value; anindication of whether the attribute value roles up to a parent node and,if so, a rollup function; an indication of whether the value is acalculated value and, if so, a calculation function; and an indicationof whether the attribute is a time-phased attribute and, if so, the typeof time phased attribute, etc. One skilled in the art will recognizethat even if the attribute is not a dimensioned attribute, the attributevalue definition 314 may be stored in the table 320 using the samemechanism as for a dimensioned attribute instead of being storeddirectly in the attribute definition 310 as shown in FIG. 3. (Althoughattribute value definition 314 can be represented by the same structureas 330, storing the attribute value definition outside of thedimensioned attribute table may yield processing efficiencies.)

Once the object type definitions have been created using the object typemanagement component of the MODMS, then a user of the application thatincorporates the MODMS can instantiate meta-objects using a meta-objectinstantiation component of the MODMS. FIG. 4 is an example block diagramof an example meta-object. Meta-object 400 includes an identifier of thetype of object that is instantiated 401, a name 402, an identifier ofthe instantiated object 403, and an attribute block 404, which storesthe collection of attribute values for all of the attributes defined forthe object type denoted by object type identifier 401. The attributevalue definitions of each attribute (such as those described withreference to FIG. 3) are used to determine how each attribute value inattribute block 404 is to be interpreted and treated. In one embodiment,the attribute block is implemented as a “tagged” data structure of,typically, alphanumeric text that represents the value for eachattribute between a set of tags, such as XML tags. So, as shown in FIG.4, the first attribute value is delimited with the beginning tag“<Attribute 1>” and with the ending tag “</Attribute 1>.” The tag usedin the attribute block 404 corresponds to the tag defined as tag name312 in FIG. 3. Each meta-object 400 typically includes other fields,such as: an indicator 405 to a table of methods 420 that define thebehavior of each meta-object 400; an indication of a parent meta-object406 in an instance hierarchy; a flag 407 that indicates whether theobject has any associated children meta-objects; indicators 408 to thechildren meta-objects of meta-object 400 in the instance hierarchy;lifecycle information 409; and other fields (not shown) 410.

One perspective of the attribute block 404 is that of a serialized“cache” of attribute values within an instantiated object. Because theattribute block 404 contains serialized data and stores each attributevalue in a normalized (standard) fashion, the values of the attributescan be easily persisted, for example, using well-known databasemanagement technology. In addition, the tag methodology of the block 404allows the attribute cache to be searched efficiently. Because ameta-object is an abstraction provided by the MODMS, one skilled in theart will recognize that the abstraction can be physically implementedaccording to a variety of techniques. For example, when an alreadyinstantiated meta-object is read and assembled from persistent storageto be manipulated by the MODMS, the various implementations of an MODMSmay temporarily store the attribute values of attribute block 404information as discrete data structures using traditionalobject-oriented techniques that instantiate objects for each value basedupon the attribute type, etc. Other techniques, such as more traditionalmonolithic programming techniques may also be employed to implement ameta-object abstraction. From the perspective of a user of anapplication built upon MODMS, however, each meta-object looks and actsthe same regardless of the type of object that is instantiated.

If one of the attribute values of the attribute block 404 is atime-phased value, then the value is more specifically described as aseries of time-phased values, where each time-phased value is in effectover a range of time. For example, a time-phased attribute may have adiscrete value for each week over a three-year period. FIG. 5 is anexample block diagram of an in-memory data structure representation oftime-phased attribute. Each time-phased attribute 501 has an associatedtime-phased attribute type 502; an indicator 503 to a collection of oneor more time-phased buckets 510; and pointers to the methods 504 thatcan be used to manipulate the type of time-phased attribute denoted bytype 502. For example, a time-phased attribute typically defines methodsfor getting and setting values for a particular range. Each time-phasedbucket 510 is a data structure that indicates the range over which avalue is effective. For example, each bucket 510 may comprise a buckettype 511, a value 512 for the range indicated, a start time periodindication 513, a duration 514 that defines the range (for example, innumber of hours, days, quarters, years, etc.), and an indicator 515 tothe next bucket in the collection or that signifies the end of the list.

Note that the values of a time-phased attribute can be stored in theattribute block 404 delimited by tags in a manner that is similar toevery other attribute value. In this case, a bucket collection isdelimited by a pair of tags, which in turn contains nested tags thatdefine the values (value, start time period, duration) for each timebucket. For example, if “Administration” is the tag name of atime-phased (labor) attribute type, then the cache for the time bucketsmay read as:

<Administration> <Bucket Collection> < Bucket> 100, 1/1/2003, 30</Bucket> <Bucket> 250, 2/1/2003, 28 </Bucket> ... </Bucket Collection></Administration>The text “100, 1/1/2003, 30” in this example indicates 100 units (oflabor), a start date of Jan. 1, 2003, and a duration of 30 days. Thevalue of each bucket type is preferably stored in its smallest unit, sothat it can be easily converted to other time period units as needed.

Since a typical application that incorporates a MODMS creates andmanages a very large collection of data, the physical representation ofmeta-objects can effect the efficiency of the application. In a typicalimplementation of a MODMS, each meta-object is stored as records in amultitude of tables, which are accessed by the management and analysiscomponents of the MODMS as needed. FIG. 6 is a block diagram of anexample storage representation of a meta-object. In FIG. 6, instantiatedmeta-object 601 is an abstract data structure representation of themeta-object 400 shown in FIG. 4 and contains the same fields: name 602;an object identifier 603; an identification of the object type 604; anattribute block 605, and other fields (not shown). The instantiatedmeta-object 601 is shown stored as records in object table 610 andnative attribute tables 620 and 630. Only some of the tables used torepresent meta-object 601 are shown in FIG. 6. For each object, theMODMS stores a record in object table 610 that contains the objectidentifier 611, the name of the object 612, an identifier of the objecttype 613, and an indicator 614 to the (tagged) attribute block. Oneskilled in the art will recognize that instead of an indicator to theattribute block, the tagged text may be stored in the object tableitself. The fields in each record in object table 610 thus correspond tothe meta-object data structure 601. For each attribute indicated by theattribute block indicator 614, the MODMS also stores a record in a tablethat corresponds to the “native” type of the attribute, thuscross-referencing the meta-objects by native attribute type. Forexample, if the attribute block contains an attribute that ultimatelyresolves to a “number,” then a record is created in a number attributetable 620 that indexes the meta-object 601. Or, for example, if theattribute block contains an attribute that is of a type that isultimately a money attribute, then a record is created in a moneyattribute table 630. Example native attribute types include such typesas numbers, dates, money, text, flags, and time-phase attributes,although one skilled in the art will recognize that depending upon theuse of the MODMS, different native types may be useful. Storage of eachattribute in these various native attribute type tables allowsattributes to be indexed and accessed efficiently based upon theirtypes, as opposed to searching each instantiated meta-object forinstances that have attributes of a specific type. This capability maybe useful, for example, when an attribute definition is changed and allof the objects that have been instantiated using that definition need tobe updated accordingly. Thus, each record in a native type attributetable indicates the object identifier 623 of the correspondinginstantiated meta-object 601 that contains an attribute value of thattype. For example, each record in number attribute table 620 stores theattribute name 621; an identifier of the attribute (sub)type 622; theidentifier of the corresponding instantiated meta-object 623; and thevalue 624 specified for that attribute in the instantiated meta-object.

As previously mentioned, a meta-object is instantiated as part of ahierarchy of object instances. FIG. 7 is a block diagram of anabstraction of an example meta-object instance hierarchy created usingan example Meta-Object Data Management System. The meta-object instancehierarchy defines the containment relationships of the instantiatedmeta-objects and is independent of the object type definitions. That is,any meta-object can be a child of any other meta-object providing it isinstantiated as a child of that meta-object. This allows, for example,different types of investments to become part of other types ofinvestments and to “behave” like they belong to the parent investmentwithout worrying about the strict inheritance rules of traditionalobject-oriented programming techniques. (Using traditionalobject-oriented techniques, an object can be manipulated using the samemethods as its “parent” object of a different object type only if thechild object type definition is derived when it is created from theparent object type definition.) So, in FIG. 7, for example, a portfolio“A” meta-object 701 contains a portfolio “B” meta-object 720; twoproduct “F” and “G” meta-objects 721 and 722; and an asset “I”meta-object 723. Further, the portfolio “B” meta-object 720 contains aproject collection “E” meta-object 732; program “C” meta-object 730, andprogram “D” meta-object 731. The program “C” meta-object 730 furthercontains a project collection “F” meta-object 740. Conversely, projectcollection “E” meta-object 732 contains a program “J” meta-object 741.Thus, in one case a program type meta-object is a parent of a projectcollection type meta-object; whereas, in the other case, a projectcollection meta-object is a parent of a program meta-object. Thus, thecontainment relationships define the object ancestral relationships andnot the object definitions themselves.

Once meta-objects have been instantiated to correspond to the initialdata set, a command interpreter is invoked to manage the data and toprovide analysis functions. FIG. 8 is an example overview flow diagramof a command interpreter for an example Meta-Object Data ManagementSystem. In step 801, the MODMS allows a user (for example, anadministrator of an application that incorporates the MODMS) to add,modify, or delete global attributes. An example global attributes tablewas described with reference to FIG. 2. In step 802, the MODMS allows auser to add, modify, or delete an object type definition such as thatdescribed with reference to FIG. 3. In step 803, the MODMS allows a userto add, modify, or delete instantiated meta-objects from the meta-objectinstance hierarchy, for example, the hierarchy shown with reference toFIG. 7.

One skilled in the art will recognize that there are many well-knownmethods for implementing the addition, deletion, and modification ofglobal attributes and the addition and deletion of object typedefinitions and of instantiated meta-objects. For example, an interfacesuch as a dialog box-based interface, a form based application, or adirect manipulation interface can be used to modify tables that storeglobal attributes, object type definitions, and meta-objects. Asmentioned previously, modifications to an object type definition,however, result in automatic adjustments to instantiated objects. Thus,when an object type definition is modified, the MODMS preferably locatesall instantiated objects of that object type and modifies their contentsaccordingly to bring them up to date. FIGS. 9-12 describe some of theroutines used to modify object type definitions and to automaticallyadjust instantiated objects as a result. Analysis routines are typicallytied to the applications that incorporate the MODMS and so are discussedas they relate to datasheet capabilities of an example portfoliomanagement system embodiment described with reference to FIGS. 17-28.

FIG. 9 is an example flow diagram of a Change Object Type Definitionroutine for modifying an object type definition in an exampleMeta-Object Data Management System. This routine can be used, forexample, to change the attributes of an investment type such as a“project.” The routine is shown with steps for modifying an object typeby adding a new attribute definition, and assumes a higher level userinterface for selection of the change to be made (i.e., what attributeto delete or add). One skilled in the art will easily recognize how tomodify the routine to change an existing attribute by deleting adesignated one and replacing it with a new attribute definition or howto modify it in other ways. The routine thus takes as input adesignation of the object type whose definition is to be modified, and anew attribute definition.

Specifically, in step 901, the MODMS retrieves the object typedefinition designated by the object_type_ID input parameter. In step902, the MODMS modifies the retrieved object type definition by addingthe new attribute definition that was designated as an input parameterto the routine. This new attribute definition is typically provided, forexample, by an I/O interface to an administrator that is permitted tochange the definition of attributes in a global attribute table. Next,in step 903, the MODMS queries the meta-object instantiation hierarchyto locate all of the instantiated objects of the designated object type.Since each stored meta-object includes an indication of its object type,the instantiation hierarchy is searched based upon that field. Steps904-907 execute a loop that, for each matching meta-object, updates themeta-object with the new attribute definition and adjusts attributesthat have rollup characteristics as necessary. More specifically, instep 904, the routine determines whether there are more meta-objects toprocess and, if so, continues in step 905, else continues in step 907.In step 905, the next instantiated meta-object is determined. Then, instep 906, an Update Meta-Object routine is invoked to add the newattribute definition to the current instantiated meta-object beingprocessed and to perform any specified calculations, and the routinereturns to the beginning of the loop in step 904. The Update Meta-Objectroutine is described further with reference to FIG. 10. In step 907,once all of the meta-objects that need to be updated have been updated,an Adjust Rollups routine is invoked to update the entire instantiationtree by adjusting any attributes with rollup values, since thedefinitions of instantiated meta-objects may have changed. The AdjustRollups routine described further with reference to FIG. 11.

FIG. 10 is an example flow diagram of an Update Meta-Object routine formodifying an instantiated meta-object in an example Meta-Object DataManagement System when its object type definition has changed. There aredifferent ways that an object type definition may have been changed andsubsequently affect instantiated objects. For example, a new attribute(hence, a new attribute definition) may have been added to the objecttype, an attribute may have been removed from the object type, or otherparts of the definition of an attribute may have been changed. Oneskilled in the art will recognize that there are may ways to implementthe Update Meta-Object function to update instantiated objects of amodified object type and that, if an attribute was changed in theunderlying object type definition as opposed to added or deleted, updateoperations can be simplified by treating modification the same as anaddition followed by a deletion. The example routine shown in FIG. 10either removes an existing attribute tag/value pair from an attributeblock of an instantiated meta-object or adds a new attribute tag/valuepair to the attribute block. Any calculations indicated by thecorresponding new attribute definition are performed as necessary. Thus,several input parameters are specified for the Update Meta-Objectroutine including a designated meta-object instance to update, the typeof update needed (e.g., add or delete or both for a modification), and adesignated attribute tag (from which a new attribute definition can bedetermined).

More specifically, in step 1001, if a new attribute is to be added tothe meta-object instance indicated by the designated object identifier,then the routine continues in step 1002, else continues in step 1007. Instep 1002, the designated new attribute tag and a corresponding endingtag are added to the attribute block (for example, attribute block 605in FIG. 6). In step 1003, the attribute definition that corresponds tothe designated tag is retrieved from, for example, the global attributestable. In step 1004, if the retrieved attribute definition indicatesthat the value of the attribute is to be calculated, then in step 1005the calculation is performed and the resultant value stored in theattribute block of the indicated meta-object instance. Otherwise, instep 1006, a default value indicated by the retrieved attributedefinition is stored between the attribute tag pair in the attributeblock. In step 1007, if an attribute is to be removed from themeta-object instance indicated by the designated object identifier, thenthe routine continues in step 1008, else returns. In step 1008, theattribute tag/value pair that corresponds to the designated attributetag is removed from or somehow nullified in the attribute block, and theroutine then returns.

FIG. 11 is an example flow diagram of an Adjust Rollups routine foradjusting rollup attributes. This routine takes a designated sub-tree ofa meta-object instantiation hierarchy and, from the leaf nodes on up,executes all attribute rollup functions that exist in any node. Therollup functions are preferably executed from the bottom of the treeupward so that they are properly aggregated progressively at each higherlevel in the hierarchy and thus properly reflect the values of thechildren nodes. There are many methods for performing adjustment ofrollups, and the one illustrated keeps track of in a rollup event list(accumulates indicators to) all of the nodes that need to have theirrollup functions executed in the proper order, and then executes therollup functions of these nodes (as rollup events) in order accordingly.

Specifically, in step 1101, the routine obtains a graph of all theobjects in the meta-object instance hierarchy from the designatedsub-tree pointer downward to the leaf nodes. One skilled in the art willrecognize that the implementation of this step is typically dependentupon the storage representation for the instantiation hierarchy. In step1102, the routine determines a list of the leaf nodes of that sub-tree.In steps 1103-1109, the routine executes a loop for each leaf node todetermine whether it has a rolled-up attribute and, if so, adds an eventcorresponding to that rollup to a list of rollup events to be executed.After the list is accumulated, the rollup events are executed in theorder that they were added to the list, thus insuring properaggregation. More specifically, in step 1103, the routine determineswhether there are any more leaf nodes in the graph, and, if so,continues in step 1105, else continues in step 1104. In step 1105, theroutine gets the next leaf node indicated by the sub-tree graph. In step1106, the routine determines from the object type system whether thecurrent node corresponds to a type of object which has rolled-upattributes. In one embodiment, each object type has a list of theattributes it contains (an object-specific rollup attribute list) thathave values that roll up (referred to for convenience as rollupattributes). Alternatively, a list of attributes that need to berolled-up for that object type can be dynamically generated. Steps1107-1109 execute a loop for each of these rollup attributes to add arollup event to the roll up list. Specifically, in step 1107, if thereare more rollup attributes for that object to be processed, then theroutine continues in step 1108, else returns to look at the next leafnode in step 1103. In step 1108, the routine gets the next rollupattribute from the object-specific rollup attribute list. In step 1109,the routine adds a rollup event that corresponds to that rollupattribute to the rollup event list. A rollup event includes, forexample, an indication of the current node in the instantiation sub-treeand a pointer to an attribute that needs to be rolled up so that, whenthe event is executed, the correct rollup function can be found and thecorresponding value(s) of the attribute can be determined. Example codefor an example rollup event is described with reference to FIG. 12. Instep 1104, once the routine determines that there are no more leaf nodesto process, the routine executes the Execute_Rollup_List routine (notshown) to execute all of the rollup events on the rollup event list thathave been accumulated thus far, and then returns. Note that it is onlynecessary to examine the leaf nodes initially and to add rollup eventsfor the leaf nodes, because each rollup event for a leaf node in turnwill add rollup events for the parent node of each of these nodes (seeFIG. 12). These nodes will in turn add rollup events for their parentnode, and the entire process will bubble up similarly so that eventuallyall necessary rollup events from the leaf node all the way to thehighest parent node across each level of the instantiation sub-tree willbe added and executed.

As described, rollup event code is executed for each rollup event thathas been added to the rollup event list. FIG. 12 is an example flowdiagram of steps executed by a typical rollup event. One skilled in theart will recognize that other code are possible and that this is justone example for ensuring that attributes are rolled up from the leafnodes all the way to the root node of the designated sub-tree. In step1201, the rollup event code determines, based upon a designatedattribute and node pointer, the particular rollup function for thedesignated attribute. In step 1202, if there is no rollup functionspecified (the definition is incomplete) then the code returns, othercontinues in step 1203. In step 1203, the rollup event code determines alist of the children of the current designated node and the parent nodeof the designated node. In steps 1204-1207, the routine executes a loopto aggregate the corresponding attribute values of the designatedattribute of the children nodes with the designated node so that theaggregated value can be stored in the parent node. The code also adds arollup event corresponding to the parent node and the designatedattribute so that the process can bubble up the hierarchy. Morespecifically, in step 1204, the routine determines whether there aremore children nodes of the designated node, and, if so, continues instep 1206, else continues in step 1205. In step 1206, the routine getsthe next child node to process. In step 1207, the routine updates an(accumulating) aggregated value with the corresponding attribute valuefrom the current child and saves it until all of the values areretrieved from all the children of the designated node. For example, ifthe total cost is the attribute being computed and the rollup functionis a summation function, then step 1207 contains a temporary variablefor collecting a sum of the total cost attribute of each of the childrennodes. The routine then returns to step 1204 to look for the next childnode to process. In step 1205, when there are no more children nodes ofthe designated node to process, the routine adds a rollup event tocorrespond to the parent node of the designated node and designates thecurrent attribute being processed, and then returns.

FIG. 13 is an example block diagram of a general purpose computer systemfor practicing embodiments of a Meta-Object Data Management System. Thegeneral purpose computer system 1300 may comprise one or more serverand/or client computing systems and may span distributed locations. Inaddition, each block shown may represent one or more such blocks asappropriate to a specific embodiment or may be combined with otherblocks. Moreover, the various blocks of the Meta-Object Data ManagementSystem 1310 may physically reside on one or more machines, which usestandard interprocess communication mechanisms to communicate with eachother.

In the embodiment shown, computer system 1300 comprises a computermemory (“memory”) 1301, an optional display 1302, a Central ProcessingUnit (“CPU”) 1303, and Input/Output devices 1304. The Meta-Object DataManagement System (“MODMS”) 1310 is shown residing in the memory 1301.The components of the MODMS 1310 preferably execute on CPU 1303 andmanage the generation, management, and use of meta-objects, as describedin previous figures. Other downloaded code 1330 and potentially otherdata repositories 1320 also reside in the memory 1310, and preferablyexecute on one or more CPU's 1303. In a typical embodiment, the MODMS1310 includes an object type management subsystem 1311, a meta-objectinstance management subsystem 1312, input/output interfaces 1315, andone or more data repositories 1314, including, for example, investmentdata.

In an example embodiment, components of the MODMS 1310 are implementedusing standard programming techniques. One skilled in the art willrecognize that the components 1311-1315 lend themselves to distributed,object-oriented implementations and can be implemented to use relationaldatabase management systems, web-based (Internet or internet)interfaces, etc. However, any of the MODMS components 1311-1315 may beimplemented using more monolithic programming techniques as well. Inaddition, programming interfaces to the data stored by the MODMS processcan be available by standard means such as through C, C++, C#, and JavaAPI and through scripting languages such as XML, or through web serverssupporting such interfaces. The data repositories 1313 and 1314 arepreferably implemented for scalability reasons as database systemsrather than as text files, however any method for storing theapplication data and for storing the instantiated meta-objects may beused. In addition, some routines of the object type management subsystem1311 and the meta-object instance management subsystems may beimplemented as stored procedures, or methods attached to table“objects,” although other techniques are equally effective.

One skilled in the art will recognize that the MODMS 1310 may beimplemented in a distributed environment that is comprised of multiple,even heterogeneous, computer systems and networks. For example, in oneembodiment, the object type management subsystem 1311, the meta-objectinstance management subsystem 1312, and the data repositories 1313-1314are all located in physically different computer systems. In anotherembodiment, the type and instance subsystem components 1311 and 1312 ofthe MODMS 1310 are hosted each on a separate server machine and may beremotely located from the instantiated object and attribute tables whichare stored in the data repositories 1313-1314. Different configurationsand locations of programs and data are contemplated for use withtechniques of the present invention. In example embodiments, thesecomponents may execute concurrently and asynchronously; thus thecomponents may communicate using well-known message passing techniques.One skilled in the art will recognize that equivalent synchronousembodiments are also supported by an MODMS implementation. Also, othersteps could be implemented for each routine, and in different orders,and in different routines, yet still achieve the functions of the MODMS.

FIGS. 14 and 15 are example block diagrams of a client-server,network-based tiered architecture for implementing embodiments of aMeta-Object Data Management System. FIG. 14 illustrates how an MODMS maybe implemented at the web services layer as web service interfaces andhow the MODMS interacts with any type of presentation tier residingabove it and with any data access tier residing below it.

So, for example, in FIG. 14, the web services interfaces 1420, which aretypically structured application programming interfaces (“API”),communicate through encapsulated data access (data abstractions) tovarious databases. The layers in a data access layer bind the dataabstractions into the various databases physically used in the system inorder to manage the physical storage. For example, the web servicesinterfaces 1420 communicate (eventually) through an accessor layer 1435to a data access layer 1450, which communicates to lower level dataaccess libraries 1451 (for example, ADO.NET). These access libraries1451 provide interfaces to the various physical database managementsystems such as a relational database management systems 1452-1454. Theweb services layer 1430 contains web service interfaces (API) 1420 whichare used by the presentation tier 1410 to access the various webservices.

The web service layer 1430 provides support for the MODMS functions. Thevarious capabilities of a MODMS are implemented as services, such asobject services 1431, licensing services 1432, and user permissions andrelated services 1433. Access to the MODMS services is provided by webservices framework 1434 through calls to the web services interfaces1420.

As continued in FIG. 15, presentation tier 1510 (1410 in FIG. 14)interfaces with the MODMS services through calls to the various webservices 1431-1433 using the web service interfaces 1520. In addition,various connectors 1540 to other third-party environments can interfacethrough the web service interfaces 1520 to take advantage of theunderlying technology. For example, connectors to programs such asMicrosoft Project Server, and Pacific Edge's Project Office caninterface through the web services interfaces 1520 to import data intothe MODMS and to export data to those the third-party programs.

The presentation tier 1510 provides the input/output interface between,for example, a client web browser 1540 and the web services layer 1530of the MODMS. The presentation layer 1510 typically comprises some typeof page server 1514 (for example, ASP.NET); a navigation and userinterface framework 1515; and various page definitions 1512 which aretransported through the page server 1514 to the client web browser 1540.The pages 1512 may reference various class libraries provided by thesystem 1513. In addition, in some embodiments, the presentation layer1510 may provide charting support 1511 and other application-specificmodules (not shown).

In an example embodiment, the majority of the functions that weredescribed with respect to FIGS. 1-12 are implemented in the objectservices layer 1531 of the web services 1530. FIG. 16 is an exampleblock diagram of components of an example object services layer of aMeta-Object Data Management System used to implement an exampleEnterprise Portfolio Management System. To implement an MODMS, theobject services 1600 comprises a command layer 1601; and variousengines/subsystems 1602-1606 for implementing the functionality of theobject type system and meta-object instantiation systems describedearlier. For example, a typical object services layer 1600 may comprisean object instance system 1607; an object type system 1603 with anadministration module 1604 for modifying object types; a time-phasedsubsystem 1605; a milestone subsystem 1606; and a math engine 1602. Asdescribed earlier, administrators use the type system module 1603 todefine and manage object types in the system. The instance system 1607is used to instantiate meta-objects of those types. The math engine1602, time-phased subsystem 1605, and milestone subsystem 1606 are shownas supplemental components; however, one skilled in the art willrecognize that their functionality may be incorporated into the othermodules as appropriate.

As described in FIGS. 1-12, a meta-object data management system may beused to create applications such as an enterprise portfolio managementsystem. In an enterprise portfolio management system, object types arecreated for each “investment” type to be managed by the system and, asportfolios are added to the system that contain investments,corresponding objects (meta-objects) are instantiated appropriately.

FIG. 17 is a block diagram of an example Enterprise Portfolio ManagementSystem implemented using an example Meta-Object Data Management System.In an example embodiment, the enterprise portfolio management system1700 comprises a portfolio manager 1702, a portfolio analyzer 1703, anda portfolio administration interface 1704. These components provide thedifferent enterprise (investment) data management and analysiscapabilities and are accessed by a user of the portfolio managementsystem through an input/output interface 1705. Components 1702-1704communicate with the meta-object data management system 1701 through thedifferent programmatic interfaces (e.g., the web service interfacesshown in FIG. 14) that access the object services layer of the MODMS1701. In addition, as discussed with respect to FIGS. 14 and 15,connector modules 1706 to external systems may also be present andaccess the meta-object data management system 1701. For example,connector modules 1706 may connect to accounting systems, human resourcesystems, and financial systems otherwise available in the enterprise.Further, these systems may be legacy applications that pre-existed theenterprise portfolio management system 1701.

FIG. 18 is a block diagram of an example investment instance hierarchyof a hypothetical enterprise portfolio management system created using aMeta-Object Data Management System. For the purposes of FIG. 18, it ispresumed that the enterprise organization comprises severalsub-organizations including corporate management 1810, engineering 1811,finance 1812, and information technology 1813 portions of theorganization. It is presumed also that each of the sub-organizations1810-1813 comprise several departments, which each may desire toorganize their own portfolio data, hence maintain and analyzeinvestments, in their own particular ways. In addition, the investmentdata may be stored in data formats and on databases that are specific tothat portion of the organization. So for example, as with most portfoliomanagement systems, some portions of organizations within the enterprisemay want to view the data in a partitioned fashion to analyzeinvestments at a lower (more detailed) level, while other portions ofthe organization, such as the management executive committee members,may want to view all of the data of the various sub-organizations at asummary level. The different size boxes shown in FIG. 18 and linked toother size boxes, such as portfolio 1832, program 1840, project 1841,and project 1842 are provided to demonstrate that any type of investmentcan be contained in any other type of investment simply by virtue of itscontainment position within the hierarchy. So for example, a portfoliotype object 1832 contains a project type object 1841, which contains aprogram type object 1853, even though elsewhere in the hierarchy, aprogram type object 1840 contains a project type object 1850demonstrating the opposite containment relationship.

As described with respect to FIG. 17, the example enterprise portfoliomanagement system comprises portfolio management functions, portfolioanalysis functions, and portfolio administrative functions. Examplescreen displays of some of the functionality provided by thesecomponents are illustrated in Appendices A and C, which are hereinincorporated by reference in their entirety. Appendix A includes screendisplays from a portfolio management interface and a portfolio analysisinterface to an executing portfolio management system. Appendix Cillustrates screen displays that exemplify the capabilities of acharting subsystem, which allows multi-dimensional data to beredisplayed in a chart using modified sets of axes, without rebuildingthe underlying chart definition. In the examples shown, the chartingsystem is integrated into the portfolio analysis interface such thateach chart is associated with a designated multi-dimensional view of thedata.

FIGS. 19-28 describe in greater detail example functions of theportfolio manager and portfolio analyzer components of an exampleenterprise portfolio management system such as that shown in FIG. 17.One skilled in the art will recognize that the capabilities shown can bemodified using well-known techniques to be suitable for the applicationdesired.

FIG. 19 is an overview flow diagram of example portfolio managementfunctions of a portfolio manager component of an example EnterprisePortfolio Management System. The portfolio manager component of anenterprise portfolio management system is responsible for creating andmanaging the meta-object instances that correspond to investment data.One skilled in the art will recognize that the functions displayed inFIG. 19 are merely examples, and a portfolio manager component may bebuilt with the same, similar, or altogether different functions. In step1901, the portfolio manager component determines what command the userhas designated to be executed. In step 1902, if the command indicatesthat a new investment object is to be added, then the portfolio managercontinues in step 1903, else continues in step 1904. In step 1903, theportfolio manager invokes an Add New Meta-Object routine to add a newmeta-object instance that corresponds to the type of investment objectdesired, and returns to step 1901 to determine and process the next usercommand. An example Add New Meta-Object routine is discussed furtherwith reference to FIG. 20. In step 1904, if the command indicates that aparticular investment object is to be deleted, then the portfoliomanager continues in step 1905, else continues in step 1906. In step1905, the portfolio manager invokes a Delete Meta-Object routine todelete the particular investment instance, and returns to step 1901 todetermine and process the next user command. An example DeleteMeta-Object routine is discussed further with reference to FIG. 22. Instep 1906, if the command indicates that the user desires to move orcopy an investment object to a different location in the investmentinstance hierarchy, then the portfolio manager continues in step 1907,else continues in step 1908. In step 1907, the portfolio manager calls aMove/Copy Meta-Object routine to move or copy the investment objectindicated, and returns to step 1901 to determine and process the nextuser command. An example Move/Copy Meta-Object routine is discussedfurther with reference to FIG. 21. In step 1908, if the commandindicates that an investment object is to be modified, then the routinecontinues in step 1909, else continues in step 1910. In step 1909, theportfolio manager invokes a Change Meta-Object routine to modify theobject instance passing appropriate information, and then returns tostep 1901 to determine and process the next user command. An exampleChange Meta-Object routine is discussed further with reference to FIG.23. In step 1910, if the command indicates that the user's view is to bechanged to a different component of the enterprise portfolio managementsystem, then the portfolio manager continues in step 1911, else returnsto step 1901 to determine and process the next user command. In step1911, the portfolio manager relinquishes control to the indicatedcomponent.

FIG. 20 is an example flow diagram of an Add New Meta-Object routine foradding a new meta-object (investment). The Add New Meta-Object routineis responsible for instantiating and adding a new investment object to aparent node in the investment object hierarchy. The routine takes asinput a designated object type and a destination location (new parentobject). In step 2001, the routine instantiates a new meta-object tocorrespond to the investment type. In step 2002, the routine populatesthe attribute block with user specified values or defaults forunspecified values. In step 2003, the routine invokes the Adjust Rollupsroutine (previously described with reference to FIG. 11) on the sub-treeof the instance hierarchy whose root is the parent node of the addedobject. The routine then returns.

FIG. 21 is an example flow diagram of a Move/Copy Meta-Object routinefor moving/copying a new meta-object (investment). The routine takes asinput a designated object, a source location (current parent object),and a destination location (new parent object) in the instancehierarchy. In step 2101, the routine retrieves the instantiated objectin the instance hierarchy that corresponds to the designated object. Instep 2102, the routine instantiates a new object of the same type ofobject as the designated object. In step 2103, the routine adds thenewly instantiated object as a child of the designated new parent object(where the new object is being moved to or copied to). In step 2104, theattribute block, including the values, is copied from the designatedobject to the new object. In step 2105, if the command has a indicatedthat a move of the investment object is desired as opposed to a copy ofthe investment object, then the routine continues in step 2106 to deletethe designated object from the current parent, else continues in step2107. Thus, a move operates similar to a copy except that the originalinvestment object is deleted. In step 2107, the routine invokes theAdjust Rollups routine (previously described with reference to FIG. 11)on the entire instance hierarchy, and returns.

FIG. 22 is an example flow diagram of a Delete Meta-Object routine fordeleting a meta-object (investment). The Delete Meta-Object routinetakes as input parameters a designated object to be deleted and a sourcelocation (current parent object). In step 2201, the routine removes thedesignated child object from the source location. In step 2202, theroutine invokes the Adjust Rollups routine (previously described withreference to FIG. 11) to adjust the rollups on the sub-tree whose rootis the source location, since one of its children objects has beendeleted. The routine then returns.

FIG. 23 is an example flow diagram of a Change Meta-Object routine forchanging an existing meta-object (investment). The Change Meta-Objectroutine takes as input a designate object and a list of attributetag-value pairs that describe values for the attributes of thedesignated object. This routine is used, for example, to change theproperties of a particular investment. In step 2301, the routineretrieves the instantiated object that corresponds to the designatedobject. In steps 2302 through 2304, the routine executes a loop for eachdesignated attribute tag-value pair to update the attribute block in theretrieved object. Specifically, in step 2302, the routine determineswhether there are more designated attribute tag-value pairs and, if so,continues in step 2303, else continues in step 2305. In step 2303, theroutines obtains the next attribute tag-value pair in the designatedlist. In step 2304, the routine updates the attribute block of theretrieved object with the particular attribute tag designated by thecurrent attribute tag-value pair, and updates the value of thatattribute in the attribute block of the retrieved object. In step 2305,the routine invokes the Adjust Rollups routine (previously describedwith reference to FIG. 11) on the sub-tree whose root is the retrievedobject, and returns.

FIG. 24 is an overview flow diagram of example portfolio analysisfunctions of a portfolio analyzer component of an example EnterprisePortfolio Management System. The portfolio analyzer component of anenterprise portfolio management system is responsible for creating andmanaging multi-dimension views of the meta-object instances and chartsthat correspond to investment data. One skilled in the art willrecognize that the functions displayed in FIG. 24 are merely examples,and a portfolio analyzer component may be built with the same, similar,or altogether different functions. In step 2401, the portfolio analysiscomponent determines the command that was selected by the user as input.In step 2402, if the command indicates that a new datasheet is to beadded, then the routine continues in step 2403, else continues in step2404. In step 2403, the portfolio analyzer component invokes a CreateMulti-Dimensional View routine to add a new multi-dimensional view tothe enterprise portfolio management system, and then returns to step2401 to determine and process the next user command. An example CreateMulti-Dimensional View routine for adding a new multi-dimensional viewis described further with reference to FIG. 25. In step 2404, if thecommand indicates that the user desires to move or copy a datasheet,then the portfolio analyzer component continues in step 2405, elsecontinues in step 2406. In step 2405, the portfolio analyzer componentinvokes a Move/Copy Multi-Dimensional View routine to move or copy anexisting multi-dimensional view, and then returns to step 2401 todetermine and process the next user command. An example Move/CopyMulti-Dimensional View routine is described further with reference toFIG. 27. In step 2406, if the command indicates that a particulardatasheet is to be deleted, then the routine continues in step 2407,else continues in step 2408. In step 2407, the portfolio analyzercomponent invokes a Delete Multi-Dimensional View routine to delete anexisting multi-dimensional view, and then returns to step 2401 todetermine and process the next user command. An example DeleteMulti-Dimensional View routine is described further with reference toFIG. 28. In step 2408, if the command indicates that the user's view isto be changed to a different component of the enterprise portfoliomanagement system, then the portfolio analyzer continues in step 2409,else returns to step 2401 to determine and process the next usercommand. In step 2409, the portfolio analyzer relinquishes control tothe indicated component.

FIG. 25 is an example flow diagram of a Create Multi-Dimensional Viewroutine for creating a multi-dimension view (datasheet) of an exampleportfolio. As described earlier, new datasheets (also referred to asmulti-dimensional views) can be defined for a particular portfolio orother object instance by populating values in a datasheet property sheetusing well-known interfaces such as dialog windows or forms. One skilledin the art will also recognize that the equivalent input may bespecified in a more “batch” oriented process, so that other code can usethe routine to build a datasheet. Specifically, in step 2501, theroutine implements a mechanism to define the various columns for the newdatasheet view. In some environments, “columns” are also known as axes,views, dimensions, or by similar terminology. In step 2502, the routineimplements a mechanism to define filtering rules. These rules are usedfilter out instances that do not match the specified rule or that matchthe specified rule, however indicated. In step 2503, the routineimplements an interface to define how instances that match the columnspecification and filtering rules are to be grouped in the resultantdatasheet. In step 2504, the routine implements an interface to definethe particular sorting algorithm to be used to order matching instanceswithin each grouping. In step 2505, the routine invokes a BuildPresentation routine to build a presentation that corresponds to the newdatasheet properties defined in steps 2501-2504. This presentation isreferred to herein as a “virtual object tree” since objects aretemporarily instantiated that correspond to the datasheet, which are notstored in the actual hierarchy or using persistent storage. An exampleBuild Presentation routine is described further with reference to FIG.26.

FIG. 26 is an example flow diagram of a Build Presentation routine forbuilding a presentation for a multi-dimension view. The routine takes asinput a indicator of a sub-tree in the instance hierarchy (typically aportfolio node) and other attributes specified by the datasheetattribute specification, such as an object type, list of relevantcolumns, filter definition, grouping list, sorting list, and aindication of an applicable security role. In summary, the buildpresentation routine queries the investment object instance hierarchy todetermine all of the investment objects that match the attributespecification of the datasheet and builds a virtual object tree thatcorresponds to the matching instances. In essence, a virtual object is atemporary object instance that is used to group the real investmentobject instances based upon the groups indicated in the attributespecification. That is, since an instance does not exist that directlycorresponds to the “group” itself and a grouping is a mere abstraction,in order for all of the rollup functions etc. to work properly, avirtual object needs to be created to correspond to each matching group,as if the group were an entity. The virtual objects look and behave likeother investment objects to a user; however they live for the life ofthe datasheet, and are instantiated when needed to present thedatasheet. Once the virtual object tree is created, then rollups areadjusted appropriately. One skilled in the art will recognize that thereare other ways to implement a datasheet, and that FIG. 26 and Table 1correspond to one of these implementation approaches.

Specifically, in step 2601, the routine queries the investment objectinstance hierarchy at the designated sub-tree according to thedesignated parameters specified in the datasheet attribute specification(see input parameter list) to determine a results table. Specifically,the query locates objects of the designated object type that have thedesignated columns and that correspond to the grouping, filtering, andsorting rules previously indicated and designated as input parameters.The designated group list is a list of each grouping of matchinginstances. For example, investments may be grouped by “rank” and then bygeographic region. Once grouped, then the designating sorting rules areused to order matching instances within a group (the results of thequery). Appendix A shows examples of resultant datasheets with attributespecifications having multiple groups and sorting rules.

In step 2602, the routine filters the resulting table of instances basedupon the security roles that are indicated by the designated securityroles. For example, different security roles can be defined fordifferent users and organizational groupings, etc., and the roles can beused to filter the data users have access to and what types ofinvestment data can be viewed via the datasheets. Different securityroles may be defined that correspond to modification access permissionsas well as what data may be viewable. The security roles may directlycorrelate to the organizational hierarchy, which may also be reflectedin the actual containment hierarchy of the investment instances.

In step 2603, a new virtual object tree root node (a virtual object) iscreated. In step 2604, a Build_VO_Tree routine is invoked to build avirtual object tree from the resultant table of instances that wasreturned as a result of the query. The pseudo code for an exampleBuild_VO_Tree routine is described further with reference to Table 1. Instep 2605, the routine invokes the Adjust Rollups routine described withreference to FIG. 11 on the newly created virtual object tree so thatrollups can be properly computed for the datasheet. The routine thenreturns the instantiated virtual object tree, which corresponds to thedatasheet.

TABLE 1  1 Build_VO_Tree (root, group_list, query_string) {  2  3curr_group = head (group_list);  4 new_grp_list = rest (group_list);  5# for each value in current group, starting with the first, ending withthe last  6 for value = first_value (curr_group), next (curr_group,last_value (curr_group) {  7  8 subroot = create_new_virtual_object;  910 if (new_grp_list = null) { 11 # find all data that matches currentsent of group values 12 leaf_table = query_results_table ( concat(query_string, 13 curr_group, value)); 14 for row in leaf_table { 15 #add pointers from subroot to all data that matches 16 add_row_as_child(subroot, row); 17 # update subroot attributes based on row data 18update_subroot_attributes (subroot, row); 19 }; 20 if (result != 0) { 21# integrate new leaf node (virtual object) into VO tree 22 add_child(root, subroot); 23 # update root attributes based upon those of new VO24 update_root_attributes (root, subroot); 25 } # no data exists withcurrent group value 26 else delete (subroot); 27 } 28 else { 29 #recurse to build a child sub-tree with current group = value 30 child =Build_VO_Tree (subroot, new_grp_list, 31 concat (query_string,curr_group, value)); 32 # add the newly built child into the currentsub-tree 33 add_child (root, child); 34 # update root attributes basedupon those of child 35 update_root_attributes (root, child); 36 }; 37 };# end loop on current group values 38 39 return (root); 40 }

Table 1 contains pseudo code for an example Build_VO_Tree routine. Asillustrated, the Build_VO_Tree routine implements a recursive processfor building up a virtual object tree from the results of a query of theinvestment instance hierarchy based up a datasheet attributespecification. It is assumed that the results of the query are intabular form, or otherwise easily decomposed, and that the results aregrouped and sorted in the order that they should be displayed. Oneskilled in the art will recognize that this is not a requirement andthat the pseudo code for the Build_VO_Tree routine could be modifiedappropriately. Also, iterative equivalents of the recursive processcould be equivalently substituted.

In summary, the routine builds a virtual object tree whose leaf nodespoint to investment data. The routine operates from the “inside” out(leaf nodes up). That is, the datasheet is effectively a tree turnedsideways, where the innermost groupings are the leaf nodes, theinvestment data that matches the innermost grouping are indicated inthese leaf nodes, and the next level of grouping is the next “level” ofintermediate virtual object nodes in the tree, and so forth. Virtualobjects need to be created for each intermediate (group) node in thetree, since instantiated objects exist only for investment data. Thus,examining a datasheet excerpt shown in a Summary View of the PortfolioAnalyzer display screens in Appendix A, a subset of which is alsodisplayed in Table 2 below, the investment data results are groupedfirst by Region values and grouped second by Score values. Under eachcombination of Region/Score values, there are 0 to N investment objectsinstances with those values. There are M levels of virtual objects foreach M levels of groups. Thus, a virtual object is preferably createdfor each grouping (combination) value, with indicators to theinstantiated investments, and a virtual object is needed for eachdiscrete value (or combined value) of each group of groups, and so on.

TABLE 2 Name Budget Region Score Status Total Cost Region: 2 $81,000 2$72,000 Score: 2 $27,000 2 $24,000 Project 3 $13,000 2 2 Green $12,000Project 2 $9,000 2 2 Red $8,000 Project 1 $5,000 2 2 Green $4,000 Score:3 $26,000 3 $23,000 Project A $11,000 2 3 Yellow $10,000 Project 4$8,000 2 3 Green $7,000 Region: 1 1 Score: 1 1 . . . 1 1 Score: 3 3

For example, looking at Table 2, a virtual object is created for a[region=2; score=2] leaf node; a [region=2; score=3] leaf node; a[region=1; score=1] leaf node; and a [region=1; score=3] leaf node. Eachof these become children of an “intermediate” virtual object node, inthis case, on the outermost grouping level: a virtual object is createdfor a [region=2] node and a virtual object is created for a [region=1]node, and so on. Thus, the resulting virtual object tree has 2 levels(since there are 2 levels of groups) with a topmost root, the firstlevel corresponding to region values, and the second level correspondingto score/region values.

The pseudo code of Table 1 demonstrates an implementation of thisapproach. The loop of lines 6-37, examines each value of a currentgroup. If the innermost group (leaf nodes) has not yet been reached,then the routine is invoked recursively in line 30 to build a virtualobject tree starting with a newly created virtual object sub-tree andthe rest of the group list. This process continues until the innermostgroup is reached, in which case line 10 is true. At that point, all ofthe matching investment instances for that combination of group valuesis determined (line 12), each matching instances is added to the virtualobject leaf node (line 16), and the attributes of the virtual objectleaf node are determined (line 18). Once all of the matching instanceshave been referenced by the virtual object leaf node (line 20), then thenewly created leaf node is added into the virtual object sub-tree whoseroot is the next closest intermediate node (the parent virtual object ofthe leaf node) (line 22). The attribute values of the current root (theparent virtual object) are then updated based upon the attributes of thenewly created virtual object leaf node (line 24). When the currentinvocation of the routine then pops back up to a prior recursiveinvocation (line 30 results), then the newly build virtual objectsub-tree is added a child node to the current root of that sub-tree(line 33). The attributes of the current root are then updated toreflect the built sub-tree (line 35). In the example shown in Table 2,the current root at that point is the root of the datasheet—the entirevirtual object tree. One skilled in the art will recognize that otherimplementations, such as those that actually persist the virtual objectsthat correspond to a datasheet are also feasible.

As described earlier with respect to FIG. 24, once a datasheet iscreated, it can be moved or copied to another investment object. In oneembodiment, datasheets are associated with portfolio objects only;however, one skilled in the art will recognize that it is possible toassociate datasheets with other investment objects as well. FIG. 27 isan example flow diagram of a Move/Copy Multi-Dimensional View routinefor moving/copying a multi-dimension view. The routine takes as input avirtual object tree, an indication of a source node, and an indicationof a target (destination) node. Note that, if more than one datasheetcan be associated with a node, then an indication of which datasheet isalso an input parameter. In step 2701, the designated virtual objecttree is associated with the designated target node so that the datasheetwill become part of that investment object. The property sheet thatdefines the datasheet is also copied as appropriate to the properties ofthe designated target node so that the target node then has access tomaintain the datasheet. In step 2702, the routine invokes the BuildPresentation routine described with reference to FIG. 26 so that a newvirtual object tree that corresponds to the moved datasheet can becreated for the target node. This step is necessary since the values ofthe datasheet typically depend upon the sub-tree of nodes associatedwith the datasheet. In step 2703, if the portfolio analyzer interfacehas specified that the datasheet is to be moved, then the routinecontinues in step 2704, otherwise returns. In step 2704, the routinecalls a Delete Multi-Dimensional View routine to delete the datasheetassociated with the designated source node, and then returns.

FIG. 28 is an example flow diagram of a Delete Multi-Dimensional Viewroutine for deleting a multi-dimension view. This routine allows a userto delete an existing datasheet. The routine takes as input anindication of the parent (portfolio) node where the datasheet is to bedeleted from, and an indicator to the virtual object tree. In caseswhere more than one datasheet is supported, an indicator to thedatasheet is included as a parameter. In step 2801, the reference to thedatasheet that is specified by the virtual object tree is removed fromthe designated parent node. In step 2802, the property sheet isdisassociated from the parent node that corresponds to the designatedvirtual object tree. In step 2803, the routine then invokes the AdjustRollups routine described with reference to FIG. 11 to recalculate therollups on the sub-tree indicated by the parent node, in case valueshave been modified. The routine then returns.

In addition to creating and managing datasheets, the example portfolioanalyzer also supports dynamic charting capabilities. Appendix C showsdetailed display screens for a charting sequence from a chartingsubsystem of an example enterprise portfolio management system. A chart“vector,” which defines all of the potential axes for a particular setof charts is associated with a datasheet. The axes thus preferablycorrespond to all of the dimensions viewable in the datasheet. Once achart vector is created for a particular chart type (e.g., a bubblechart), the axes that correspond to the currently displayed presentationare dynamically selectable. Thus, the charts can redisplay theunderlying datasheet investment data, without having to be rebuild thechart structure.

All of the above U.S. patents, U.S. patent application publications,U.S. patent applications, foreign patents, foreign patent applicationsand non-patent publications referred to in this specification and/orlisted in the Application Data Sheet, including but not limited to U.S.patent application Ser. No. 10/613,534, entitled “METHOD AND SYSTEM FOROBJECT-ORIENTED MANAGEMENT OF MULTI-DIMENSIONAL DATA,” filed Jul. 3,2003; and U.S. Provisional Patent Application No. 60/471,811, entitled“METHOD AND SYSTEM FOR OBJECT-ORIENTED MANAGEMENT OF MULTI-DIMENSIONALDATA,” filed May 19, 2003, is incorporated herein by reference, in itsentirety.

From the foregoing it will be appreciated that, although specificembodiments of the invention have been described herein for purposes ofillustration, various modifications may be made without deviating fromthe spirit and scope of the invention. For example, one skilled in theart will recognize that the methods and systems for creating, managing,and analyzing heterogeneous investment data discussed herein areapplicable to other types of data management systems other thanenterprise portfolio management. For example, the techniques used hereincan be applied to homogeneous data such as streamlined inventory controlsystems or project management systems. One skilled in the art will alsorecognize that the methods and systems discussed herein are applicableto differing network protocols other than the Internet and web-basedcommunication, communication media (optical, wireless, cable, etc.) anddevices (such as wireless handsets, electronic organizers, personaldigital assistants, portable email machines, game machines, pagers,navigation devices such as GPS receivers, etc.).

1. A method in a computing system for electronically managing aplurality of types of enterprise portfolio data, the portfolio datahaving investment items, the computer system defining an object type tocorrespond to each of the plurality of types of portfolio data, eachobject type defining a plurality of attributes, comprising: undercontrol of the computing system, for each investment item, instantiatingan object as an instance of the object type that corresponds to theinvestment item, the instantiated object containing a plurality ofattributes; and setting values of the plurality of attributes of theinstantiated object based upon data associated with the investment item,wherein at least one of the investment items is a financial investmentitem that reflects financial investment data and at least another one ofthe investment items is a project management item that reflects projectrelated data and the instantiated objects that correspond to thefinancial investment item and the project management item are stored andmanaged by the computing system as interchangeable items.
 2. The methodof claim 1, further comprising: receiving additional portfolio data;dynamically adding a new object type to correspond to the received data,the new object type defining a new plurality of attributes; andinstantiating a new object as an instance of the new object type tocorrespond to the received data and setting values of the plurality ofattributes defined by the new object type based upon the received data.3. The method of claim 1 wherein sources for the portfolio data residein a plurality of separate data repositories that belong to distinctorganizations within an enterprise.
 4. The method of claim 1 wherein theinvestment items are at least two of financial investments, projectmanagement, collections of projects, products, programs, assets, humanresources, portfolios, initiatives, applications, operations, processes,and activities.
 5. The method of claim 1, the enterprise portfolio datacomprising at least two of engineering, marketing, product management,manufacturing, sales, information technology, finance, human resources,research, development, and professional services portfolios.
 6. Themethod of claim 1 wherein at least one of the attributes has multipledimensions yielding multiple sets of values for the at least oneattribute.
 7. The method of claim 6 wherein the attribute dimensions areat least two of actual value, baseline value, plan value, target value,and scenario value.
 8. A computer-readable storage medium containingcontent to control a computer processor when executed to manage aplurality of types of enterprise portfolio data, the portfolio datahaving investment items, the computer system defining an object type tocorrespond to each of the plurality of types of portfolio data, eachobject type defining a plurality of attributes, by performing a methodcomprising: a memory; for each investment item, instantiating an objectin the memory as an instance of the object type that corresponds to theinvestment item, the instantiated object containing a plurality ofattributes; and setting values of the plurality of attributes of theinstantiated object based upon data associated with the investment item;wherein at least one of the investment items is a financial investmentitem that reflects financial investment data and at least another one ofthe investment items is a project management item that reflects projectrelated data and the instantiated objects that correspond to thefinancial investment item and the project management item are stored andmanaged as interchangeable items.
 9. The computer-readable storagemedium of claim 8, the method further comprising: receiving additionalportfolio data; dynamically adding a new object type to correspond tothe received data, the new object type defining a new plurality ofattributes; and instantiating a new object in the memory as an instanceof the new object type to correspond to the received data and settingvalues of the plurality of attributes defined by the new object typebased upon the received data.
 10. The computer-readable storage mediumof claim 8 wherein sources for the portfolio data reside in a pluralityof separate data repositories that belong to distinct organizationswithin an enterprise.
 11. The computer-readable storage medium of claim8 wherein the investment items are at least two of financialinvestments, project management, collections of projects, products,programs, assets, human resources, portfolios, initiatives,applications, operations, processes, and activities.
 12. Thecomputer-readable storage medium of claim 8, the enterprise portfoliodata comprising at least two of engineering, marketing, productmanagement, manufacturing, sales, information technology, finance, humanresources, research, development, and professional services portfolios.13. The computer-readable storage medium of claim 8 wherein at least oneof the attributes has multiple dimensions yielding multiple sets ofvalues for the at least one attribute.
 14. The computer-readable storagemedium of claim 13 wherein the attribute dimensions are at least two ofactual value, baseline value, plan value, target value, and scenariovalue.
 15. The computer-readable storage medium of claim 8 wherein themedium is a memory in a computing system and the contents areinstructions that control a computer processor to perform the method.16. A portfolio management computing system for managing portfolios ofinvestment items, comprising: a memory; an object type management systemthat is configured, when executed, to define types of investments forwhich objects can be instantiated in the memory and a plurality ofattributes that are associated with each type; an object instantiationsystem that is configured, when executed, to: instantiate an object inthe memory as an instance of the object type that corresponds to aninvestment item, the instantiated object containing a plurality ofattributes; and set values of the plurality of attributes of theinstantiated object based upon data associated with the investment item,wherein at least one of the investment items is a financial investmentitem that reflects financial investment data and at least another one ofthe investment items is a project management item that reflects projectrelated data and the instantiated objects that correspond to thefinancial investment item and the project management item are stored andmanaged as interchangeable items.
 17. The system of claim 16 wherein theportfolio management system is an enterprise portfolio managementsystem.
 18. The system of claim 16 wherein the object type managementsystem is further configured to: dynamically add a new object type tocorrespond to a received additional portfolio investment item, the newobject type defining a new plurality of attributes; and the objectinstantiation system is further configured to: instantiate a new objectin the memory as an instance of the new object type to correspond to thereceived investment item; and set values of the plurality of attributesdefined by the new object type based upon the received investment item.19. The system of claim 16 wherein sources for the portfolio investmentitems reside in a plurality of separate data repositories that belong todistinct organizations within an enterprise.
 20. The system of claim 16wherein the investment items are at least two of financial investments,project management, collections of projects, products, programs, assets,human resources, portfolios, initiatives, applications, operations,processes, and activities.
 21. The system of claim 16, the portfoliocomprising at least two of engineering, marketing, product management,manufacturing, sales, information technology, finance, human resources,research, development, and professional services portfolios.
 22. Thesystem of claim 16 wherein at least one of the attributes has multipledimensions yielding multiple sets of values for the at least oneattribute.
 23. The system of claim 22 wherein the attribute dimensionsare at least two of actual value, baseline value, plan value, targetvalue, and scenario value.